Device Management Applications (DMAs) such as Xerox Device Manager (XDM) or Xerox Centre Ware Web (XCWW) are installed to manage devices such as printers or multi-function devices in a Web-based environment. Such applications allow users to discover devices and collect data from the device on a scheduled basis and display information via a network discovery protocol. The data collected from the device includes device configuration information, settings, meters, supply levels, and alerts. Among the data collected, the printer status is retrieved at scheduled configurable intervals. The status updates combine device alerts retrieved from the printer or upon configured traps from the printers.
Table 1 below illustrates an example of standard alerts that may be defined by a printer and contained in a Printer MIB (Management Information Base). In this example, each print status type is classified as a different print alert state. The device solely defines the state classification.
TABLE 1NoResponseInputTrayMissingQueueManualFeed0x40000000x80000x200000000TechDispatchReqOverduePreventMain-QueuePagePunt0x80000000000tenance 0x2000x8000000000PaperJam 0x04TonerLow 0x20NoToner 0x10LowPaper 0x80Printer State ListMarkerSupplyMissingOutputNearFull 0x1000Error 0x1000000x2000NoPaper 0x40OfflineOnly 0x20000000Printing 0x1000000OutputFull 0x800UnspecWarn 0x8000000Unspecified 0x10000OutputTrayMissingQueueAccessDeniedTesting 0x800000x40000x40000000000DoorOpen 0x08QueueNoMemory0x20000000000ServiceRequested 0x01QueuePausedWarning0x800000000x40000OfflineServiceRequestedQueuePaperProblemWarmingup 0x400000000x40000000000x2000000UnspecError QueueWaiting0x100000000x2000000000Offline 0x02QueueInterventionOkay 0x1000000x10000000000InputTrayEmptyQueuePaperProblemUpAndRunning 0x4000x4000000000x20000
FIG. 1 illustrates a screen shot 10 of an example list view of a device status of a prior art device management application. FIG. 2 illustrates a screen shot 20 of an example detailed print status in a prior art device management application. As shown in FIGS. 1 and 2, the status is available for all printers discovered with an indicator of the severity of device status or within the printer details screen in, for example, an XDM user interface (UI). Such a web based DMA may create device alert incidents based on the device status or alerts. When the application, such as an XDM, triggers the alert and updates the alert, the data is exported to another application such as, for example, a Xerox Services Manager (XSM) for the further processing to generate, for example, Device Remote Alerts (DRAs) based on the input from device status.
DMAs such as XDM or XSM offer no control over printer status alerts such as those listed in Table 1. DMAs only use this data to determine if the device is in one of these error states. No logic with DMA currently exists that can help determine the state of the device. When the device has some problems in the logic or in the firmware to determine the status of the device, false alerts will be collected in DMAs and the user might get the false alarm. In some cases, the same print status results in a different severity level of alerts.
FIG. 3 illustrates a flow chart of operations of a method 31 for implementing a Get Print Status String 31 and a method 33 for generating Get Print State Level in a prior art device management application. As shown at block 32, an operation is implemented wherein print status bits are retrieved from the device on scheduled intervals. As indicated at block 34, a print status ID type mask (e.g., status bit) is pre-generated. That is, a list of print status ID masks is pre-generated. This step involves identifying all matched print status bits. Among these, the first matched print status is identified as shown in block 36.
An operation is then implemented as indicated at block 36 to find the prioritized matched print status. The first matched status is then displayed in a UI (User Interface) as shown at block 38. Regarding method 33 (i.e., Get Print State Level), an operation can be implemented as shown at block 42 in which print status bits are retrieved from the device, followed by a determination of whether or not to generate an error state mask, as shown at block 44. The error state masks and warning state masks are pre-generated meaning that XDM has a predetermined status for each state. The steps will find the matched status against this mask. If the match is found in error mask, it is assigned as an error. The same is true with respect to a warning state.
Assuming the answer with respect to the operation depicted at block 44 is “yes,” an error is then displayed as shown at block 46. Assuming the answer with respect to the operation depicted at block 44 is “no,” a decision is then made as shown at block 48 to determine whether or not to generate a warning state mask. If the answer is “no,” then a display message indicating “okay” is generated as illustrated at block 52. If the answer is yes, then a warning can be displayed, as indicated at block 50. Note that in the context of a logic diagram, these steps can be stated as: IF found the match in error mask, it is an error state, ELSE IF found match in warning state, it is a warning state, ELSE it is in okay state.
The operations shown in FIG. 3 demonstrate how a DMA such as, for example, XDM can obtain the print status and determine alert levels and display the resulting information for users. As described in Get Print Status String routine of method 31, the print status is prioritized and top print status string matched is displayed. The priority list is defined in global settings (GS) in XDM based on business strategy decision. The priority print status list in GS is shown in Table 1.
When several print status bits are turned on, the top most matched print status to this priority list will be displayed as a string. For example, when the printer status bit of “ServiceRequired”, “LowToner”, “LowPaper”, and “Warning” are received from the device, the XDM UI displays the message “ServiceRequired” since it has the precedence over other status bits. In this case, the alert level is recorded as a warning state according to the printer state received from the device. As depicted in FIG. 1, some devices show this status alert as an error state while some devices indicate this as a warning state. FIG. 4 shows the same status for “No Toner/Ink” in different printers that show different severity levels. FIG. 4 illustrates a screen shot 40 of an example list view of a device with no toner/ink status in a prior art device management application.
FIG. 5 illustrates a screen shot 56 displaying information indicative of print status information cycles during a status polling of scheduled intervals generated by a prior art device management application. Some devices remove existing error status from its list of errors when other errors occur in the devices. This is a well-known problem in devices which cycles print status bits or print status strings. Some examples of devices that show this type of issue are shown in FIG. 5. These types of behaviors can cause unwanted alerts or notifications.